This Page Is Inserted by IFW Operations 
and is not a part of the Official Record 

BEST AVAILABLE IMAGES 



Defective images within this document are accurate representations of 
the original documents submitted by the applicant. 

Defects in the images may include (but are not limited to): 



BLACK BORDERS 



TEXT CUT OFF AT TOP. BOTTOM OR SIDES 



FADCD TEXT 



ILLEGIBLE TEXT 



SKE VV ED/SLANTED IM A G E S 



COLORED PHOTOS 



BLACK OR VERY BLACK AND WHITE DARK PHOTOS 



GRAY SCALE DOCUMENTS 



IMAGES ARE BEST AVAILABLE COPY 



As rescanning documents null not correct images, 
please do not report the images to the 
Image Problem Mailbox. 



iiiiiiiyiiiiiiiiiiiiiiiiiiiiiiii 



United States Patent [19] 

Lum et al. 



US006065041A 
[ii] Patent Number: 
[45] Date of Patent: 



6,065,041 
May 16, 2000 



[54] INTERFACE CODE ARCHITECTURE 

[75] Inventors: Lambert Chun -Bob Lum, Hayward; 

Craig Seidel, Palo Alto; Zhengo Guan, 
Mountain View, all of Calif.; James K. 
Schwarz, Jr., Boulder, Colo. 

[73] Assignee: Electronics for Imaging, Inc., Foster 
City, Calif. 

[21] Appl. No.: 08/933,126 
[22] Filed: Sep. 18, 1997 

[51] Int. CI. 7 G06F 15/16; G06F 15/177 

[52] U.S. CI 709/203; 709/220; 709/221; 

345/3 

[58] Field of Search 709/203, 220, 

' 709/221, 222, 230, 246; 345/330, 521, 
329, 204, 3, 1, 2 

[56] References Cited 

U.S. PATENT DOCUMENTS 

4,558,413 12/1985 Schmidt et al 707/203 

4,558,418 12/1985 Schmidt et al 364/300 

4,787,035 11/1988 Bourne 700/247 

4,860,247 8/1989 Uchida et al 345/521 

5,045,994 9/1991 Belfer et al 369/286 

5,289,574 2/1994 Sawyer 395/157 

5,315,711 5/1994 Barone et al 395/275 

5,388,252 2/1995 Dreste et al 395/575 

5,539,872 7/1996 Mintz et al 395/155 

5,715,444 2/1998 Danish et al 395/604 

5,734,852 3/1998 Zias et al 395/334 

5,748,189 5/1998 Trueblood 345/331 

5,768,614 6/1998 Takagi et al 395/821 

5,815,148 9/1998 Tanaka 395/333 



5,854,936 12/1998 Pickett 395/710 

5,883,613 3/1999 Iwaki 345/132 

5,897,635 4/1999 Torres et al 707/10 

5,950,011 9/1999 Albrecht et al 395/712 

FOREIGN PATENT DOCUMENTS 

0333612 9/1989 European Pat. Off G06F 9/44 

0684547 11/1995 European Pat. Off G06F 3/14 

W095/15524 6/1995 WEPO G06F 9/445 

Primary Examiner — Mehmet B. Geckil 
Attorney) Agent, or Firm — Michael A. Glenn 

[57] ABSTRACT 

A display interface system that uses a server T client approach.;; 
The server contains all of the necessary information regard- 
ing display information, while the client deals with the - 
specific display type that it is connected to. Hie server 
contains generic descriptions of user interface screens which 
allow the server to be independent of specific display types. 
T his allows one version of software to support many type s 
of displays, rather than several software revisions for each 
display type, saving the software developer time, 
maintenance, and labor costs. A request-response commu- 
nication system is used whereupon the client requests pre- 
vious or next user display screens, system parameter 
requests, or updates from the server. The client requests 
screen information through a series of key-tag sequences, 
while the server controls the sequencing of the user display 
screens. The client is shielded from any knowledge of the 
contents of the screen and is only concerned with the fact 
that something is being displayed. Communication between 
t he server and client is throug h a unified protocol, allowing 
t he client to be located either locally, in the same machin e 
or re mote, across a network. 

56 Claims, 7 Drawing Sheets 
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i^AA^In * a:plurality 



INTERFACE CODE ARCHITECTURE 

BACKGROUND OF THE INVENTION 
1. Technical Field 

The;inyendon:relates:toHhe-transfer:ofinformation:acro 



20 



25 



30 



35 



a:plurality rdf Tdissiimlar"di^lay^evices . More:particularly, 
tte-rov^tion-relatesrtora^genen^ 
arcEitecture for^transferririg' display ihforaation~from~a> 
sewer to a plurality of dissimilar display devices; thereby^ 10 
allowing the server to ignore the attributes of each particular 
display device. 

2. Description of the Prior Art 

Computer system applications that require user interac- 
tion communicate information through devices such as 15 
Liquid Crystal Displays (LCDs), Light Emitting Diode 
(LED) displays, plasma displays, and cathode ray tubes 
(CRTs). Each display type requires a specialized driver to 
control any graphical representations on the display. The 
graphical representations may be very simple, one -line 
messages, e.g. "Self Test," to very complicated graphical 
user interfaces (GUIs). 

A<^ftoareldey.eloperjm^t-CT^ 
custom tailored for each display with which his application? 
communicates. Typically, at hbrar y is cre_ated that represents 
all of the allowable graphic primitives on the screens that are 
displayed on the chosen display. TherUbrary conta^ns^infor^ 
mation such as.the scfeen "c^ti6n"primitives, button labels? 
user messages~blink characteristics, and headingsV^Built on 
tqp-of-the -library -is~a module cont airiing^ all of the" screen 
descjiptiorjs.;ThezkbTary^ 

written~in-the-programrmng language, e.g. "C," that^the^ 
software' developer is using and:customized:for:the:type;of> 
display? e.g. a one, two, or five-line LCD display, or a GUI 
display, The differences between a two-line and a five-line 
LCD display is the amount of information that can be 
displayed. A two-line LCD display is limited in the amount 
of text that can be displayed to the user as compared to a 
five-line LCD display A GUI display has much more display 
area than a line-limited LCD display. It can display on one 
screen, information that would require several screens on a 
line-limited LCD display. T he-sourc e-code -is then-compile dy 
wittrthe application^sourcc ^codeand delivered as part of the 
final product; > 

This hard coding of display screens requires that new 
source co'de be created arid compiled into the application 
software whenever a new display device is selected. The 
source cpde for each~display~type"must" be archived :;and 
maintained" for the life of each display device. This is a 
cumbersome and expensive task, e.g. there are N different 
source codes for N different display devices used. 

U.S. Pat. No. 4,787,035 issued to Bourne on Nov. 22, 
1988, discloses a system which uses an interpreter that 
examines messages using grammar and lexical tables to 
produce a parse table. The parse table is compared to data 
needed in a semantics table to fire a rule which causes a 
function table to be evaluated and performs user desired 
functions. This is particularly suitable for manufacturing 
systems with multiple target languages. 

If the product is one that is used by an Original Equipment 
Manufacturer (OEM), the OEM usually requires custom 
displays to differentiate their product from the other OEMs 
using the same base application. For an OEM engineer to 
create his custom displays, he must know the internal 
structure of the application's software. Revealing such infor- 
mation is many times a sensitive issue. The originating 



company would prefer to keep such internal software struc- 
tures confidential in an attempt to retain their value as a 
product supplier to any OEM. 

I^w^ld^e advantageous^to -provide ~a -display interface 
system that allowsthe developer to-create -a single set-of 
screen descriptions that is used for all supported display; 
types. It would further be advantageous to provide a display 
interface system that is independent of the display location, 
ix; -whether the display is embedded in the system or 
network accessible. > 

SUMMARY OF THE INVENTION 



The^ii^ntion^providesaT^cUsplayrinterface :system~mathas>i 
a genegi^parchitecture and is thereby independent of the 
supported' display type. The invention uses a generic lan- 
guage approac h that is independent of the type of display 
chosen and its location in relation to the generic code 
generator.' 

The invention uses a server-client approach. The server 
contains|all of the necessary information regarding display 
information, while the client deals with the specific display 
type to which it is connected. The server allows a software 
developer to create generic descriptions of user interface 
screens. The generic screen descriptions allow the server to 
be independent of specific display types. This allows one 
v ersion of software to support many types of displays, rather 
than several software versions for each display type. The 
software developer saves on time, maintenance, and labor 
costs. | 

A request-response communication system is used where- 
upon the| client, acting as the user interface, requests previ- 
ous or next user display screens, system parameter requests 
or updates from the server. Thus, the user interface function 
is offloaded from the server. T he client requests screen 
information through a series of key-tag sequences . User 
display screen sequencing is controlled by the server. T he 
concept ot user display screens is known only to the server. 
The cHentlis shielded from any knowledge of the contents of 
40 the screen land is only concerned with the fact that something 
is being displayed. 

Communication between the server and client is through 
a unified protocol. The server-client approach, combined 
with the^unified protocol, allows the client to be located 
either locally , in the same machine or remotely, across a 
network^ " 



BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 is a block schematic diagram of two major 
components and their interface according to the invention; 

FIG. 2 is a block schematic diagram of a full system 
implementation according to the invention; 

FIG. 3 is a block schematic diagram of a server client 
relationship according to the invention; 
£EIG£4"is^blo1^di^ 
tatton-according to the invention; 

FIG. 5 is a block schematic diagram showing a remote 
implementation utilizing the server-client relationship 
according to the invention; 

FIG. 6 is a block schematic diagram showing a local and 
remote implementation utilizing the server-client relation- 
ship according to the invention; 

FIG. 7 is a block schematic diagram showing a series of 
screens and their equivalent translations in a GUI and LCD 
environment according to the invention; 
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FIG. 8 is a block schematic diagram showing a series of 
two-line LCD displays; 

FIG, 9 is a block schematic diagram showing a sequence 
of LCD targets and their display sequence according to the 
invention; and 

FIG. 10 is a block schematic diagram showing a set of 
GUI targets displayed simultaneously on a GUI display 
according to the invention. 

DETAILED DESCRIPTION OF THE 
INVENTION 

FIG. 1 shows a Console Application Programming Tnter- 
fS£^i CAPI ) 101 and an I nterface Code Interpreter 102 
which comprise two major components of the inventionxThe 
CAPI~lOl~a llows~a~softwa re~develo0er_:to~create~generics 
des5riptio ns"of ~user"interface:screens~or^portioiisroLuser> 
interface screens, collectively referred to as "screens? ..These 
descriptions are thenjmanaged by CAPI lOl^duri^ 
ystem run-time:?A request-response communication s ystem ^ 
used whereupon the Interface Code Interpreter 102, acting 
as the direct user interface, requests previous or next in: 
sequence user display screens from CAPI101>£API~101 
controls the sequencing of all of the user display screens: 
The concept of user display screens is known only to CAPI 
101. The Interface Code Interpreter 102 only has the knowl- 
edge that something is being displayed to the user, and not 
the content of the display. 

With regard to FIG. 2, to explain the capabilities of the 
invention further, CAPI 201 and the Interface Code Inter- 
preter 202 are shown in a full system implementation. A 
Parameter Manager 203 is the interface to all of the system 
information, e.g. how many print jobs are queued on the 
system, or the Internet Protocol (IP) address. This informa- 
tion is stored in the System Database 204 and accessed by 
the Parameter Manager 203. The Interface Code Interpreter 
202 sends a value request or a value save request to CAPI 
201. CAPI 201 asks the Parameter Manager 203 for the 
appropriate value from the System Database 204, in the case 
of a value request, and sends the value response back to the 
Interface Code Interpreter 202. In the case of a value save 
request, CAPI 201 has the Parameter Manager 203 check the 
validity of the value and then update the appropriate value 
in the System Database 204. The Interface Code Interpreter 
202 communicates with the user through the Display Con- 
troller 205. The D isplay Controlle r 205 consequently dis- 
plays information to the user through the Display 206. 

Referring to FIG. 3, the invention is extended to a 
server-client relationship. The Server 301 contains the CAPI 
303 and Parameter Manager 304 components. The Client 
302 contains the Interface Code Interpreter 305 and Display 
Controller 306 components. The Server 301 and Client 302 
communicate with each other using the CAPI 303 and 
Interface Code Interpreter 305. T he Parameter Manager 304 
anHPAPJ 303 may hr. cnmhW.H together as one function^ 
component and will herein he referred to as CAPI . In this 

f embodiment of the invention, the client may communicate 
with the server after a selected action is executed locally at 
the client ^ default mode\ or client/server communication 
may occur in a direct mode , in which certain user actions are 
communicated directly tdlhe server, or in a component level 
event d riven mode, in which all user actions are communi- 
cated directly to tEe" server. 

Referring to FIG. 4, in a local implementation, the CAPj 
40^ Interface Co de Interpreter 402, and Display Controller 
403 are combined together^ thereby providing an integrated 
user interface solution. 
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With respect to FIG. 5, a network implementation is 
shown. The Server 501 contains the CAPI 502 component. 
Clients communicate with the Server 501 through a Network 
503. There may be any number of clients one 505, two 507, 
through N 508 attached to the network. Each client contains 
the Interface Code Interpreter 504 and Display Controller 
506 components. The Interface Code Interpreter 504 varies 
from one client to another depending on the capabilities of 
the display type. All requests for user interface screens are 
sent from the clients through the Network 503, to the Server 
501. 

Referring to FIG. 6, the Server 601 may have a local 
display attached to it and would then require the Interface 
Code Interpreter 603 and the Display Controller 602 com- 
ponents. Each client (and Server 601 in this case) is nor- 
mally communicating to a different user. Each user has 
different demands from the Server 601. Therefore, each 
client may have a different user interface screen displayed to 
the user. In addition, each client may have a different type of 
display. For example, client one 607, may have a GUI 
display, while client N 610 may have a five-line LCD 
display. This requires the clients to communicate to the 
Server 601 their display preferences, which is typically done 
upon the client startup or beginning of a communications 
session with the Server 601. 

The Server 601 stores screen descriptions in a script form 
in an internal database. The scripts are created by the 
programmer and define the screen contents. The Server 6 01 
i nterprets the scripts and converts it to the proper protocol 
form for a client to understand. Ae run- time interpretation 
of the scripts allows the programmer or OEM to create 
screen description scripts without re-compiling the source 
code of the Server 601. This also insulates the programmer 
and OEM from the internal structure of the Server 601 code 
and the language (e.g. C, Ada, C++) in which the code is 
written. 

The Server 601 also stores display profile descriptions in 
an internal database. The client also has a requirement for 
the language, e.g. EnglishUS, that the client wants the 
strings and screens to be displayed in. ThelSelvefr601Ttfies> 
to JMHh^closest;m^ 
profile hano^erlf^ 
size match, it looted than that' 

requested; In the case of the language, it returns the default 
language, e.g. EnglishUS, if no match is found. The Server 
601 ignores all unknown tags and unknown values from the 
client. The Server 601 dynamically creates a profile that 
matches the client's profile and returns the handle to that 
profile to the client. The client stores the profile handle and 
uses it to tell the Server 601 the types of screens and strings 
it requires. As previously mentioned, the client obtains a 
profile handle at the beginning of each communication 
session because the profile handles on the Server 601 may 
change. i , 

Theza^play^projUe;de^ Ci ^ 

ware jevel oper-to:indicate the capabilities of each type 6f> 
oUsplay;-Additionally 7 the server dynamically creates any 
additional display profiles to match the attributes of any 
previously unknown client profiles. A display may have the 
capability to display two lines of text (the smallest) or many 
lines of text (in the case of a GUI display). The CAPI system 
resizes the display output to fit the display type. CAPI 
operates on a multiple virtual LCD model, wherein the 
smallest display (two lines) constitutes a virtual LCD screen. 
Several LCD screens may be displayed on a five -line LCD. 
An even greater number (possibly ten) of LCD screens may 
be displayed on a GUI display. The software developer may 
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coalesce the virtual LCDs into logical groupings so that 
multiple LCDs are logically related when they are displayed 
simultaneously. 

With respect to FIG. 7, the coalescent behavior is shown 
using a series of server setup screens. A typical setup 
sequence allows the user to set the server name 701, system 
date 702, system time 703, whether to print a start page 704, 
and whether to save the changes made in the previous 
screens 705. A GUI display coalesces all of these screens 
onto one display 706, replacing the save changes screen 705 
with an OK button 708 and a cancel button 709. The 
decision making process of whether to coalesce the screens 
resides in the client itself. The client has the knowledge of 
the capabilities of the display that it is driving. The server 
describes a vague, abstract grouping of the screens and the 
client decides on the final grouping. For a two-line LCD 707, 
the server name screen 701 would be reduced to two lines by 
the client. 

Another concept that is brought about by the difference 
between a GUI and LCD display is that the amount of 
information that may be displayed on each display type 
varies. For example, a two- line LCD display (FIG. 8) may 
only have the ability to display a Raster Image Processor 
(RIP) screen containing the job name and number of bytes 
ripped. A GUI display (FIG, 10), on the other hand, adds 
more information such as the job's owner, the Postscript file 
size, and ripping time. This is called Variable Content. 

Incyariat3leXontent~m~e7se^ 
a run-time screen. The client picks and chooses which part 
of the contents of the screen it displays and which part it 
does not display. The decision is up to the client in custom- 
izing the contents according to the size of the display that it 
is driving. This results in a semi-chaotic interpretation of the 35 
screens. The | advantage of this style of interpretation is that 
it allows the c lient to decicje on the layout and attributes ( e g 
font, size and color) of each screen. The outputs may vary 
bety^enTdispiay types. 

40 

Referring to FIG. 9, each type of screen is considered a 
target. An idle screen 801 is currently visible 806 in an LCD 
example. There are other targets that the user is able to scroll 
through, such as a function menu target 802, RIP target 803, 
print target 804, and alert target 805. The LCD targets are 
only active when there is information other than idle to 
display. An idle target display 801 indicates that all other 
targets are in an idle state. 

With respect to FIG. 10, GUI targets are displayed on a 
GUI display 905. All targets such as the RIP target 901, alert 50 
target 902, function menutab sheet target 903, and print 
target 904 are visible. If any targets go into an idle state, then 
they indicate so. There is no need for a summary target as in 
the LCD example. 

Input from the user can be predetermined on the client 55 
side. It is up to the client to decide at what level it pauses for 
user input. The server, on the other hand, does not know 
when an input event occurs. 

In a preferred embodiment of the invention, CAPI allows 60 
the software developer to use a grammar that is a superset of 
the C programming language to create user interface screen 
descriptions. Qne^killedrm^the-art^will readily appreciate* 
that^other-languages-such -as-Ada, G++r and o pnrietarp 
gga ttfipg , -grammars^ may be used instead of or in combina? 65 
tion with Cr> The following is an example of a C based 
approach. 



CAPI grammar (C based) 

A sample code section is shown that demonstrates the 
similar structure of the CAPI grammar with the C language. 



int 

servcrSetup (void) 
{ 

BEGIN(asscClusterSavable) 
BEGIN(textPair) 

moText("KSERVERNAME"); /* Server Name •/ 
moEntryT«tt(*'XJ7_SERVER" ) NULL, 10); 
END 

BEGIN(datePair) 

moT>xt("KS YSTEMD ATE* '); I* System Date •/ 
moEntryDate("sysdate"); 
END 

BEGIN(timePair) 

moTcxt("KSYSTEMTIME"); /* System Time •/ 

moEntryTiine( M systimc*'); 
END 
END 

Teturn CHOICE_JNTOTHING; 

} 
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The inner BEGIN . . . END pairs represent small LCD 
screens, i.e. virtual LCD screens. While the outer BEGIN . . . 
END pair represents a group or cluster of small LCD 
screens. 

The pairs and clusters may also be represented as a tree of 
array function pointers. Apair may be coded as one function, 
and a cluster function may contain code to register the 
function pointer of the pair. The function pointers are 
collected in an array and may be executed in any order. 

For larger displays, such as GUI displays, these virtual 
LCD screens coalesce into dialog boxes. The inner 
BEGIN . . . END pairs represents lines in a dialog box. The 
outer BEGIN . . . END pair will represent a dialog box itself. 
The BEGIN . . . END Operators 

BEGIN . . . END pairs are implemented by means of 
macros in the C programming language. The following is a 
typical definition of the operators: 



^define BEGIN(funPtr) \ 
begin(funPti); \ 
{ 

#definc END(funPtr) \ 
}\ 

end( ); 



The begin() function takes a function pointer as a param- 
eter. Inside beginQ, the function pointer is de -referenced and 
called. The de-referenced function pointer performs some 
type of setup operation, then the function pointer is pushed 
onto a stack for end() to use later. 

The end() function pops the function pointer off the stack 
and performs a table lookup for a corresponding ending 
function that describes how to shut down the code block. 

The following is an example of an actual code section: 



BEGIN(textPair) 
END 

BEGINO starts and textPair() is called. TextPairO clears 
the screen and sends the cursor to the upper left hand corner 
of the screen. The function pointer textPairQ is then pushed 
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on the stack. ENDQ executes later and the function pointer 
textPairO is popped off of the stack. The function end() 
performs a table look up of textpairO to find the complement 
function. The function endTextPainQ is found in the table. 
EndTextPairO is called and collects input from the user. 

When BEGIN . . . END pairs are nested they form a 
cluster. A cluster is a grouping of smaller BEGIN . . . END 
pairs. On a GUI display, a cluster is equivalent to a dialog 
box. 

The function pointers that are passed as parameters add to 
the flexibility of the system. For example, there are several 
functions with the suffix of Pairs in the previous examples. 
The functions textPairQ, datePairQ, and timePairO call a 
generic function called pair(). This is an example of abstrac- 
tion where a function can be customized for any special 
need. 

The IF . . . ELSE . . . ENDIF Operators 

The operators IF, ELSE, and ENDIF may be defined 
specifically to fit the application. For example: 



tfdefine IF if 
#definc ELSE else 
^define ENDIF /• nothing V 

On other applications, IF and ELSE may be redefined to 
allow unconditional traversal of both branches of a condi- 
tional branch. 
The BREAK Operator 

The Break operator takes the program execution to the 
point just past the nearest END macro. Because the BEGIN 
and END macros may perform some behind the scenes 
operation, BREAK was developed to properly shut down 
those operations when trying to break out. 
CAPI Screen Primitives 

Screen primitives are identified by their prefix, mo 
(malleable output). They are named for reconfigur ability. 
For example: 



BEGIN(selectPair) 
moTbxt^KPRTSTARTPG''); /* Print Start Page */ 
moEntrySe]ect("PKrSTARrPG*', "KYES", "KNO", 
/* Yes, No */ 

END 



NULL); 



behavior of mo primitives or nested BEGIN . . . END pairs. 
The mo functions are designed to be directed by associative 
primitives. The mo functions observe certain status set up by 
associatives and attempt to conform to them. 

5 A second purpose of associatives is to perform implicit 
operations. For example, cluster associatives implicitly posi- 
tion a "save changes" screen at the end of a group of setup 
screens or an implicit OK button. 

Associatives can also be rewritten for customization. For 

10 example, if a software developer is porting from a small 
screen LCD to a GUI display, the cluster associative is 
rewritten to create a dialog box instead of a series of screens. 
The pair associative is composed of two mo primitives to 
create a line within a dialog box. 

15 The following is a description of a server/client commu- 
nication protocol in a preferred embodiment of the inven- 
tion. 

Description of the Protocol 
Instead of computing all of the layout details and man- 
20 aging all of the user controls on the server, CAPI offloads the 

User Interface (UI) interaction onto a client application (e.g. 

an LCD display client on the server, or remote applications 

written in Java). The client application communicates with 

CAPI using the protocol described herein. 
25 CAPI^nisur^ort-temoterapplications on-all^platfofms^ 

w^ch-underetand-the^mfieli"^^ 

varietiesrcaD be driven by-a single protocol wen though" they 
differ-in many ways,—, 

^The communication between the client application and 
30 CAPI server can be viewed as a request-response dialog. 
Each time the client application requires the next screen, it 
sends a screen request to CAPI and CAPI responds with the 
description of the next screen. The client must supply the 
handle of its current screen in the request. The protocol also 
35 pays attention to user input from the client application to 
CAPI, so the server can keep track of which screen to send 
at the next request. Possible requests include: next screen; 
previous screen; descent to next menu; and ascent from 
menu. 

Values from the Parameter j ^nager^are handled in the 
same manner. The client application sends a' value request or- 
a_valu^save:request"and"CAPrsends back a value response- 
orjryalue save'response^ 
Keys:&iValues^> 

TheteTis an associated~key~fni- each" text" string .'( both * 
localized and non-localized^ choice in selection lists;. and ■> 
screen :( cluster:or vw). This kevJs used by CAPI to i dentify ' 
all data and screens. , Kevs are also- manipulated, stored, and 
retrieved by the Parameter Manager. 

^^ r ^£®d^^-Plrt^^?3ch key, the set key and the dala 
keyrUsing dot;notation; a key is in the form of S.D, where 
S is the set key and D is the data key. 

CAPI:has^three-types of values: string, numerical, and; 
Boolean-- Because^ the client has no information on 
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Thcrfiinction:moTextO - takes a ~language_key„parameter 
and outputsa localized string to the screen - MoEntrySelectQ^ 
produces a selection choice list. The first value is a sysdict 

key that^is used for obtaining a default value and writing so 
back ,the value into the sysdict. The other strings are lan- 
guage keys whose localized form composes the choice list. 
The NULL designates the ending parameter in a variable 
argument list. 

On any platform, the functionality of these mo functions 55 localization, all strings sent to the client have to be pre- 
can be rewritten allowing for arbitrary customization. :Eat2 localized by the server. For example, when choosing -a 

example,^ anTapplication^rnay want to r edirect the outoii t to selection from a selection entry, the client must tell the 

more than rone destination, e.g. multiple virtual LCDs or it server which choice it is setting. The client application send s 

may want to record a play back file. CAPI does not enforce b ack the key of the choice (e.g. true") rather than sendin g 

any mo display. The exact form and appearance of display 60 b ack the localized selection string (e.g. si (Spanish)) , 

primitives^ determined by the client application. CAPI "Forrnumerical" vahiesrthere is no key associated^ with the 

only gives hints and suggestions of the form and appearance value~a ndJl>i» = cUent sends^baclTttie~-value 

^f-primidves and-selectionsr> [Client Profile 

CAPI Associative Primitives * — Before the cAPl server can send back the description of 

In the previous examples, function pointers were passed 65 screens or respond to any requests to the client application, 

into BEGIN. These function pointers are a class of primi- the server must know what the client can display (i.e. 

tives known as associatives. Associatives influence the whether the client is a two line LCD, five line LCD, or Java 



—4. scyrefcA^ 



tot 
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GUI application which can display long strings) and in 
which language the client wants the strings and screens to 
be. 11ns is called the Client Profile 

-^The client application employs the following format in 
performing the client profile handshaking: 
From client to server: 
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10 

met. For example, when the Parallel Port is disabled, all of 
the configuration entries in the Parallel Port Setup page are 
deactivated. 

Propagation is performed on the server side and not on the 
5 client side. Whenever propagation occurs, the server sends 
updates of the values to the client. The client is responsible 
for refreshing the display. The update is as follows: 



#GETPROFILE# 
Tkg_\t_ Va]ue_\n_ 
Tfeg_\t_Value_\n_ 

Tiig_\t_Value 



10 



From server back to client: 



#RETURNPROnUE#_\t_ProfUe_Handle 



25 



30 



As an example, the tags can be lang and localSize. The 
value for the tag lang is the language that the client is trying 
to display, e.g. EnglishUS, French, or German. The value for 
the tag localSize tells the server the display size and whether 
the client is LCD or GUI, e.g. LCD5x20, LCD2xl6, or GUI. 

After the server receives the tags and values, it tries to 
lookup the closest match to the client profile and return the 
profile handle. If it does not find an exact string size match, 
it looks for a string size shorter than the requested one. In the 
case of language, it returns the default, e.g. Englishlntl or 
EnglishUS, depending on the system. The server ignores all 
unknown tags and unknown values. 
~* Thej ClienkApptouonrto 
usw-jHrrrequestrng^ 

isjadvisablerot^hard code-the -orofn^haTiHte-nr^t^Tf 
offlip^Therclient3application~should"perform~the profile 35 
re^uest-eyery;session;(notevery:request though) because;the: 
profile handle-might vary from different server versions: 
ValMty^©epenQ^ncy~and:Eropagatipn-^ 
^^Vah'Qitpindicates whether a parameter's value is consis- 
, tent with the correct operation of the system. For example, 40 
j a negative value for a polling interval is invalid. Sometimes 
; the user can only select from a few choices, making any 
f other values invalid. 



Depe^dency-controls whether the user can change the 
1 values in a certain entry. In the present protocol, dependency 
\ lists are sent to the client describing the dependency of an 
gentry or a menu item. 

i \ Prop'a^ffb'hs^re triggers which are activated^when the 
\ user changes some values which cause "cHtmre^HionsV' An 
example is when the user changes a value on the current 
page, thereby causing values in the pages encountered 
beforehand after to be changed. 

^VatioUty is maintained on LCD CAPI platforms using 
choice lists, numeric selection, range testing inside CAPI, 
and some programmatic C functions in the screen descrip- 
tion files. Additionally, control flow dependency is used on 
LCD platforms rather than dependency lists. Therefore, 
CAPI skips the screen if the condition is not met. 
caMalidity^is the responsibility of the client application on 
GUI platforms. The protocol includes either all the possible 
choices (e.g. moEntrySelect) or the range of values the user 
can pick (e.g. moEntry Number) for each entry. The client 
application validates the user input before sending it back to 
the server. Parameter Manager also validates the input on the 
server side. 

GUI applications use^ciependencya lists to deactivate (gray 
out) entries and tabsheets when certain conditions are not 
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#UPDATE#_\n_ 
Kcy__\t_ Value 
[_\n w JCey_\t_ Value . 



Note: If the value of a selection is #??#, this indicates the 
15 client should erase the choice list. The #UPDATE# is 
immediately followed by a #RETURNOPTION# (the new 
choice list) with the corresponding key. 

The update is easily performed if the client does not store 
any keys and values other than those currently displayed and 
20 the update does not affect the current page. When the client 
requests a new screen, the values in the new screen are 
up-to-date, so no special measures are required. 

When::the : clie n t-applicatiop-keeps-track-of ~ke ys~and 
valuesrit changes the sto red" value hrmemory and refreshes 
the corresponding display upon receiprof tbe updates. 

The most difficult part is when the update affects display 
and values of the current screen. This scenario requires 
Direct Mode or Component Level Event Driven. 
Qireet^Mode£> 

^"Direct Mode is similar to the "Wizard" in GUI environ- 
ments. The application guides the user, one step at a time for 
each screen. Upon completing a change to one value or 
reading one message, the user can click on the NEXT button 
and go to the next step. 

Propagation is easily achieved in direct mode because the 
client only receives one pair at a time. Therefore, propaga- 
tion on the same screen does not occur. Also, flow control is 
totally controlled by the server, so no hiding or graying out 
of any components of the display is necessary. 

Direct mode is activated by the "direct" tag in #SCREEN- 
RESPOND#. All client applications must support direct 
mode. 

Component-I^vel^Event-Driven:(CLED)^ 

During normal CAPI client-server interactions, the only 
time the client sends back requests is when the user is 
finished with the current screen and is trying to go to another 
screen. This is also the only time the client application is 
expecting anything from the server. 

CLED differs from the normal situation. Each time the 
user changes anything or presses a button, the client sends 
back the value it is trying to set. The servers then send back 
the updates. This back-and-forth value exchange continues 
until the user is finished with the current screen, saves the 
values, and proceeds to the next screen. 

CLED is activated by the "cled" tag in #SCREENRE- 
SPONDtf. 
55 Target Display Area 

The server may occasionally send information, warning, 
and error messages to the client in addition to the regular 
screen display. The client application is responsible for 
displaying and distinguishing these messages from the regu- 
60 lar display. For example, on a GUI application, the user may 
see an informational message on a pop-up dialog box and 
warning/error messages on another type of pop-up dialog 
box. While on an LCD display, the user presses a menu 
button to see a message on the information screen for 
65 informational messages, or presses the menu button again to 
see warnings and errors on alert screens with the warning 
LED flashing. 
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Each display area is referred to as a target. The client Set Parameter Value: set a parameter's current values, 
application supplies the target screen as a required parameter 
in each screen request. This tells the server the target for 



which the next screen description is intended. In each screen #setvalue# [_\t_tagj_\n_ 

response, the server supplies a target tag so the client knows 5 key„\t_vahie [_\n_J«y_\t_vaiue . . . ] 

where to display the screen description. If there are any ~ ■ - — — ^ 

informational messages, warnings, or errors, the server t , c Ct ^„„™ , Af rTr „ 

sends two or more screen descriptions. All screen descrip- ™ ere * an °P ^ ta g fiel ? after #SETVALUE#. 

tions are directed to specified targets. ^ ta S s include tem P and canceL 

The message flash differs from all of the other targets. One 10 c Get Parameter's Vahd Options: obtain the valid options 

example of a message flash is: "Configuring Token Ring for the P arameter and lts de ^ v ^e. 
Hardware. Wait 1 min." After receiving any message flash, 
the client application displays the message to the user and 

waits for the server to signal that it is ready again. The server #GETOFTiON#_\n_ 

also supplies a maximum timeout with the message flash 15 _\t_Jcey (_\n_key . . . ] 

target. If the client expires on this maximum timeout, it can — ^— ^ _ 



send another screen request to the server. The cbent apph- * n — * t * *• * * . i iL 

.j , * i_ j • i Get Parameter Information: get parameter type, length, 

cation considers the server to be down or the connection lost read/write etc 
depending on the number of timeout expirations. 
Details of the Protocol 20 

The syntax of the protocol is covered in two sections. The ^ 
first is the protocol from the client application to the server #GEnNFO#_\n_ 

(CAPI) and the second is the protocol from the server _\t_key [_\n_key . ] 

(CAPI) back to the client. 

Note: __/t_ denotes a TAB character and _/n_ denotes a 25 Get Profile: get client profile handle for the closest 
NEWLINE character. matched supported localization and display. 

The TAB character is used as a delimiter for tokens on the 
same line, and the NEWLINE character is used to indicate 

the end of a token list. For debugging and readability, TAB ^— ^ 
characters are introduced at the beginning of a line to 30 #GETPROFTLE#_\n_ 

provide indentation. The client application ignores all of the tag_\t_value L\a_tag_\t_vaiuc . . . ] 

TAB characters at the beginning of a line. 

Client to Server (CAPI) Protocol Server (CAPI) to Client Protocol 

The Client initiates the request by first sending the Client The server side of the protocol are responses to the 
Profile and other information to the server. After that infor- 35 client's requests. The most common response is the 
mation is sent, it can begin its request for screens. #SCREENRESPOND#. 



#IAM#_AL_Profile_Handle_\n_ 
[T^g__\t_Value_\n _. . . Tag_\t_Value__\n_] 

tfSCREENREQUESW^t^igeL-Scree^t.ScreeiiKeyJ^WhichScreen 



The "tag- value" list is optional and it provides a place for 45 
transferring extra information from the client to the server. 
The server ignores all unknown tags and values. 

The keyword #IAM# requires one parameter, namely the 
Profile Handle, obtained from the Client Profile Request, 50 

The #SCREENREQUEST# keyword has three param- 
eters. The first parameter is the target screen of the client's 
primary target screen, e.g. setup, the second is a screen key 
of the current screen, and the third is a command for either 55 
previous or next, with respect to the screen key. 

Besides screen requests, the client application can also 
request the following services: 

Get Parameter Value: used to get a parameter's current 60 
value. 



#SCREENRESONfD#_\t„Ikrget_Screeo_\t_ScrecnKey_\n_ 
[Tag_\t_Value_\n_ . . . Tag_\t_\klue_\n_] 
. . . Screen Description . . . 



Tags include waitForServer (used with target mesgFlash), 
active, direct and cled. 



waitForSeiver: parameter is in units of milliseconds, 
parameter 0 means do not need to wait for server, 
e.g. waitForServer 60000 means wait for server to get 
ready again, with a maximum timeout of 6000O 
milliseconds - 1 minute. 



^ direct: 
#GETVALUE#_\n_ 

key [_U_key . . . ] 65 



true means direct mode is ON 
false means direct mode is OFF. 

rf a #SCREENRESPOND# does not contain the direct tag, 
it is defaulted to be false. 
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-continued 



Cluster Block ::= 

#BEGIN#_\t_asscCluster | asscCIusterSavable_\n_ 

#END#_\n_ 
* 'I* denotes OR in the syntax, i.e. 
#BEGIN#_\t_asscauster_\n_ . . . #END#_\n„ 
-OR- 

#BEGIN#_\t_asscClusterSavable_\n_ . . . #END#_\n_ 
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clcd: true means CLED is ON 
raise means CLED is OFF. 

If a #SCREENRESPOND# does not contain the cled tag, 
it is defaulted to be false. 



All client applications must support Direct Mode. 

In the CAPI screen description, there are three layers: 
cluster, pair, and mo. Mo is the basic primitive, e.g. text 
label, entry box, selection list, checkbox, and buttons. A pair 
is a collection of two mo's, usually a text label and an entry 
component or display component. A cluster is a collection of 
pairs. 

As disclosed above, CAPI does not enforce any mo 
display. The exact form and appearance of display primitives 
is determined by the client application. CAPI only gives 
hints and suggestions of the form and appearance of primi- 
tives and selections. This is also true for pair and cluster 
displays. CAPI only provides grouping hints and informa- 
tion. The client application can and is responsible in the 
actual layout of the components. The client application 
ignores and skips unknown clusters, pairs, and mo's. 

A cluster corresponds to a group of related screens on 
LCD platforms, e.g. all the screens in a Server Setup 
submenu, or a single page on GUI-based platforms, e.g. a 
server setup dialog box. 

AsscCluster is a regular cluster block, and asscQuster- 
Savable indicates a Save Screen or Save button is required 
when the user tries to exit the cluster. 



A pair corresponds to a single screen on LCD platforms. 
On GUI platforms, a pair is usually a line in a dialog box. 



Pair Block 

#BEGIN#_\t_datePair | timePair | ipPair | textPair | selectPair_\n_ 
#END#_\n_ 
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ClusterTitie:sets:toe:tiLle^^^ 
contain"scveral~scfeens on LCD platforms ora^s 
iorTGUI-based platforms).^ 

For LCDs, MoTitle sets the title for the current screen 
only. The title in the other screens in the same cluster are not 
changed. For GUIs, MoTitle is used to set the title of only 
the menu screen. 

MoNoTitle is used when no title is desired in the current 
screen. 



Cluster Tile" Statement ::= 

clusterTitle__\n_ 

Key_\t_Title String__\n_ 
moHtle Statement ::= 

moTitle_\n_ 

Key_\t_Title String_\n„ 
moNoTItle Statement ::= 

moMoTile_\n_ 
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MoText:puts.up-a-text-string-on-screen.- 
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moText Statement 
moText_\n_ 
Key_\L_Text String_\n_ 



For each entry (query) and menu item, there may be 
dependency list attached to it. 




MenuScreen-i s— a-regular— menu— or— tabshe et^and 
me nuScreenSavaBle-req uires-a-save-screen-oriSaverbuttonl 



Menu Block 

#BEGIN#__\t_menu Screen | menuScreenSavable__\n_ 
#END#_\n_ 



45 



50 



KeySiga Value ::= 

key == value | key != value 
DepcndancyList 

#REQUIRES#_\t_BoolExp 
BoolExpr::** 

KeySign Value | && BoolExpr BoolExp | 



CMesgScreen-p uts-a-messa geiscreen~up^wi"th-an^QK J -^ 
tbujtonrjhe user needs to press the button before it proceeds 
to another screen. mesgFlashScreen is the same as mesg- 
Screen with no "OK" button. It can be taken down by the 
system at any time. Currently, GUI applications get the 
message block description directed for a message target 
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Message Block ::- 
#BEGIN#_\t_me5gFlashScreen | mesgScrecn_\n 

#END#_Vn_ 
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| BookExpr BoolExpr 



MoEntry's are the primitives on the screen. Each moEntry 
js a query linked t o a key. The key refers to data t hat can be 
manipulated by Parameter Manager. 



moEntryDate Statement ::- 
mo Entr yDa te_\n_ 

Key_\t_ ValueString [ _\t_DependancyLisfL-\n__ 

FormatStringKey„\t_FormatString_\n_ 
* FormatString is a combination of "MM", "DD", "YY" and 

delimiters, e.g. MM/DD/YY, DD.MM.YY, YY-MM-DD 

ValueString in the form of the format string using the same 

delimiters, e.g. 09/01/96, 01.09.96, 96-09-01 

FormatStringKey is the key of the FormatString. FormatString 

should be treated as another localized string in the language 

dictionary or in the Parameter Manager. 
moEntryTime Statement ::= 

mo EntryTime_\n_ 

Key_\t_ ValueString [_\t_Dependa ncyList J_\n_ 
FormatStringKey_\l_Fo rmatString_\n_ 
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-continued 



-continued 



* FormatString is a combination of "hh", "mm" and delimiters, 
e.g. hh:mm, hh.mm 

ValueString in the form of the format string using the same 
delimiters, e.g. 00:01, 16.30 

Forma tStringKey is the key of the Forma tString. FormatString 
should be treated as another localized string in the language 
dictionary or in the Parameter Manager. 
moEntryIP Statement ::» 
mo Entry IP_\n_ 

Key_\t_ ValueString [_\t_DependancyList]__\n_ 

* ValueString in the form of #.#.#.# where # can be from 0 to 255 
e.g. 125.0.11.2 

moEntry Number Statement ::>» 
moEntryNumber_\n_ 

Key__\t_ ValueString [_\t_DependancylistJ_\n_ 
Range 

* ValueString (integer string, can be positive, zero or negative) 

* Each Range has the format 

Lower Bound [.. Higher bound [@ Step]], 
and multiple ranges are separated by commas 
moEntryText Statement ::» 
moEntryText_\n_ 

Key [_\t_ ValueString] [_\t__Z>ependancyList}_\n_ 
Maximum Length {integer string, must be positive)_\n_ 

* ValueString is the default text, can be empty. 
moEntryTextSecret (Password) Statement ::- 

mo Entry 1extSecret_\n_ 

Key [__\t_ ValueString] [ \t _DependancyList]_\n_ 

Maximum Length (integer string, must be positive)_\n 

* ValueString is the default text, can be empty. 
moEntry Select Statement ::- 

mo Entry Sclcct_\n_ 

Key[_\L_ ValueString] [_\t_.DependancyList]_\n_ 
ChoiccList 

* ValueString is the choice key. [f left empty, 
the first choice will be used as the default value. 

ChoiceList 

Key \n_ Value 

[_\L_Key_\t_ Value . . . ] 
moEntryTbggle Statement ::= 

Same as moEntrySelect Statement 

* rnoEntryTbggle is similar to moEntrySelect. moEntrySelect can be 
realized as a selection list (option list / list box widget), while a 
moEntryToggle can be realized as a checkbox or radiobox (radio buttons) 
primitive. 

However, the difference is just given as a hint to the client application, 
which still has the final decision in how to display the screen. 



Value is the current value, so if the set request fails, the client 
can show the current value. 

The flag is an integer where 0 indicates the value is set, and 

otheT number is error status (for debugging purpose only). 

The server may send #SCREENRESPOND# to different targets, e.g. info, 

warning or error messages, before #SETRESPOND#. 



Respond to Get Parameter's Valid Options 
(#GETOPTION#): 

return the parameter's valid options and the default value. 
The options are the current set allowable values based on 
information provided by Parameter Manager. 
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#RETURNOPTION#_\n_Jiey_\t„ 
Defaults Value [_Option...] 

[„\t_#RErURNOPTION#_\t_kcy„\rL_Default_Valuc 
20 l_\t_Option ...]...] 

Note: The first option returned is the default value. The 
number of options vary, depending on what is active on the 
server. Also, each #RETURNOPTION# contains only ONE 
25 key. Therefore, one #GETOPTION# request can result in 
more than one #RETURN0PTlON# response. 

Respond to Get Parameter Information (#GETINFO#): 

return the parameter's information. 

30 

#RETURNINFO#_\n_ 

key__\n_tag_\t_value [_\t_tag_\n_value ...] 
[_\L_key_\t_tag__\t_valuc [_\t_tag_\n__valuc ...]...] 
Tags include type, length, read, write, uscrtype. 
35 Value corresponds to each tag, e.g. length 4, type U8, uscrtype date. 



Respond to Get Profile (#GETPROFILE#): 
return the closest matched client profile handle. 
#RETURNPROFILE#_Profile_Handle 
Propagation Value Update 



MoMenultem is a link to further screens in the menu 
screen. 

On a GUI platform, a menu is realized in two ways, either 
a row/column of buttons or a tabsheet (property sheet). The 
choice is determined by the GUI application. 



moMenultem Statement 

moMenultem [_\t Pep endancy List] \n 

Key_\t__Menu Item String \t_ 



Besides the screen description, the protocol covers other 
request- respond communications. 



Respond to Get Parameter Value (#GETVALUE#) : 
return the parameter's current value. 

#RETURNVALUE#_\n_ 

Key_\t_ Value [__\L_Key_\n_ Value . . , ] 
Respond to Set Parameter Value (#SETVALUE#) : 
tell the client application if the values are set 

#SETRESPOND#_\n_ 

Key_Flag_ Value 

[__\t_Key_U_Flag_\n_ Value . . . ] 
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#UPDATE#__\n„ 
key__\t_value 
[__\t_key_\n_value ,..] 



Note: If the value of a selection is #??#, this indicates the client should 
erase the choice list. The #UPDATE# will be immediately followed by a 
#RETURNOPTtON# (the new choice list) with the corresponding key. 

50 Control Panel Map Generator 

A control panel map is a map of all of the LCD screens. 
Clients have the power to traverse pairs and clusters. Usually 
traversal is initiated by the user. Unlike user initiated 
traversal, a control panel map generator unconditionally 

55 traverses all of the links to assemble a map of all of the LCD 
screens. This is very useful for the creation of documenta- 
tion. 

Due to the organization of the server and client, any 
changes or additions to screens on the server results in the 

eo update of only the server software. The client has no 
knowledge of the number of screens that exist on the server, 
only that it has a screen handle from the server. 

One skilled in the art can readily appreciate that these 
techniques can be applied in a different manner in relation to 

65 the server and the client. For example, the client's Interface 
Code Interpreter stores the display profile descriptions in an 
internal database. The server sends the client generic screen 
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descriptions in response to the client's requests. The client 
uses the display profile that fits its display type to translate 
the generic screen description and display the screen to the 
user. 
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is^mpatible^with^ all^possibleTdispla^tvpes. Tflusjrjesultsii n? 
ajlaj^o^time^andtemamt^^ 

ggnejriG^eonstructs allow an OEM^ to create user interface 
screens*without requiring any knowledge of the product's^ 
software^arehiteeturef^ 

Although the invention is described herein with reference 
to the preferred embodiment, one skilled in the art will 
readily appreciate that other applications may be substituted 
for those set forth herein without departing from the spirit 
and scope of the present invention. Accordingly, the inven- 
tion should only be limited by the Claims included below. 
aWhatSis^laimed?is!# 

1. A process for displaying user interface screens on a 
plurality of dissimilar display devices using a unified inter- 
face expression, comprising the steps of: 

creating a list of generic user interface screen descriptions 
at a server; 

identifying the display type associated with a client; 
updating a client display using said generic user interface 

screen descriptions, 
wherein said generic user interface screen description 

describes an abstract grouping of virtual screens to be 

displayed; 

wherein said display type ranges from a two-line display 

to a GUI display; 
wherein said client decides whether to coalesce said 

virtual screens to customize the contents to said display 

type; and 

wherein said client and server may optionally be 
co-located. 

2. The process of claim 1, further comprising the steps of: 
creating a list of display type profiles at said server; and 40 
selecting the appropriate display type profile from said 

display type list that is the closest equivalent to said 
client's display type profile; 
wherein said updating step sends said generic interface 
screen descriptions to said client according to said 
selected display type profile. 

3. The process of claim 1, further comprising the step of: 
creating a list of supported language types at said server. 

4. The process of claim 3, further comprising the steps of: 
selecting the appropriate language type from said lan- 
guage type list that is the closest equivalent to said 
client's language type; and 

configuring said generic screen descriptions to match said 
selected language type. 

5. The process of claim 3, further comprising the steps of: 
converting said generic screen descriptions into protocol 

screen descriptions; 

selecting the appropriate language type from said lan- 
guage type list that is the closest equivalent to said 
client's language type; and 

configuring said protocol screen descriptions to match 
said selected language type. 

6. The process of claim 1, further comprising the step of: 
responding to a client's screen request by sending the 

appropriate generic screen description to said client. 
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7. The process of claim 6, further comprising the step of: 
sending the key value corresponding to said appropriate 

generic screen description to said client. 

8. The process of claim 1, further comprising the step of: 
responding to a client's request for a system parameter 

value by sending an appropriate system parameter 
value to said client. 

9. The process of claim 1, further comprising the step of: 
updating the appropriate system parameter value with a 

value sent by a client. 

10. The process of claim 1, further comprising the step of: 
responding to a client's screen request by sending an 

appropriate generic screen description to said client 
through a network. 

11. The process of claim 10, further comprising the step 

of: 

sending a key value corresponding to said appropriate 
generic screen description to said client through a 
network. 

12. The process of claim 1, further comprising the step of: 
responding to a client's request for a system parameter 

value by sending an appropriate system parameter 
value to said client through a network. 

13. The process of claim 1, wherein said generic user 
interface screen descriptions are created in such a manner as 
to allow each screen to be displayed on any one of said 
dissimilar display devices. 

14. The process of claim 1, further comprising the steps 

of: 

creating a list of display type profiles at said client; 
selecting the appropriate display type profile from said 

display type list that is the closest equivalent to said 

client's display type profile; 
receiving said generic interface screen descriptions from 

said server; and 
displaying said screen descriptions to a user using said 

selected display type profile to interpret said screen 

descriptions. 

15. The process of claim 1, further comprising the steps 

of: 

receiving said generic interface screen descriptions on 
said client from said server; and 

displaying said generic interface screen descriptions on 
said client to a user by combining said screen descrip- 
tions to accommodate the display capability of the 
display type attached to said client, 

16. The process of claim 1, further comprising the steps 

f: 

receiving said generic interface screen descriptions on 
said client from said server; and 

displaying said generic interface screen descriptions on 
said client to a user by displaying as much of the 
contents of said screen descriptions to accommodate 
the display capability of a display type attached to said 
client. 

17. The process of claim 1, further comprising the steps 

f: 

converting said generic screen descriptions into protocol 
screen descriptions. 

18. The process of claim 17, further comprising the steps 
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creating a list of display type profiles at said server; and 
selecting the appropriate display type profile from said 

display type list that is the closest equivalent to said 

client's display type profile; 
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wherein said updating step sends said protocol screen said console application programming interface compris- 

descriptions to said client according to said selected ing a list of generic user interface screen descriptions; 

display type profile. said console application programming interface compris- 

19. The process of claim 17, further comprising the step ing a module for updating a client display using said 
°f ; 5 generic user interface screen descriptions; 

responding to a client's screen request by sending the wherein said generic user interface screen description 

appropriate protocol screen description to said client. describes an abstract grouping of virtual screens to be 

20. The process of claim 19, further comprising the step displayed; 

°f* wherein said client display ranges from a two-line display 

sending the key value corresponding to said appropriate 10 to a GUI display; and 

protocol screen description to said client. wherein a client decides whether to coalesce said virtual 

21. The process of claim 17, further comprising the step screens to customize the contents to said client display. 
°f ; 30. The apparatus of claim 29, said console application 

responding to a client's screen request by sending the 15 programming interface further comprising: 

appropriate protocol screen description to said client a list of display type profiles; 

through a network. a module for selecting the appropriate display type profile 

22. The process of claim 21, further comprising the step from said display type list that is the closest equivalent 
°f ; to said client's display type profile; and 

sending a key value corresponding to said appropriate 2 o where in said updating module sends said generic interface 

protocol screen description to said client through a screen descriptions to said client according to said 

network. selected display type profile. 

23. The process of claim 17, wherein said protocol screen 31. The apparatus of claim 29, said console application 
descriptions are created in such a manner as to allow each programming interface further comprising: 

screen to be displayed on any one of said dissimilar display 25 a ^ 0 f supported language types. 

devices. 32. The apparatus of claim 31, said console application 

24. The process of claim 17, further comprising the steps programming interface further comprising: 

°f* a module for selecting the appropriate language type from 

creating a list of display type profiles at said client; said language type list that is the closest equivalent to 

selecting the appropriate display type profile from said 30 said client's language type; and 

display type list that is the closest equivalent to said a module for configuring said generic screen descriptions 

client's display type profile; to match said selected language type, 

receiving said protocol screen descriptions from said 33 • The apparatus of claim 31, said console application 

server; and programming interface further comprising: 

displaying said protocol screen descriptions to a user 35 a module for converting said generic screen descriptions 

using said selected display type profile to interpret said into Protocol screen descriptions; 

screen descriptions. a module for selecting the appropriate language type from 

25. The process of claim 17, further comprising the steps sa i d language type list that is the closest equivalent to 
0 f : said client's language type; and 

receiving said protocol screen descriptions on said client * a module for configuring said protocol screen descriptions 

from said server; and to match said selected language type. 

.... . . . . . . • 34. The apparatus of claim 29. said console application 

displaying said protocol screen descriptions on said client . . , c . _ 4l . . rr 

. , ... r . . programming interface further comprising: 

to a user by combining said screen descriptions to , , f , 

accommodate the display capability of the display type 45 a mo *| lc fo u r responding to a client s screen request by 

attached to said client. sendin ? tbe a PP ro P nate S eneric screen description to 



26. The process of claim 17, further comprising the steps 



said client. 



0 f. ' * 35. The apparatus of claim 34, said console application 

. . . , programming interface further comprising: 

receiving said protocol screen descriptions on said client , , c ,. 4 , , , j- * j 
from said server- and 50 a m °oule for sending the key value corresponding to said 

r m ai ' a appropriate generic screen description to said client, 

displaying said protocol screen descriptions on said client 36 ^ apparatus of claim 29, said console application 

to a user by displaying as much of the contents of said programming interface further comprising: 

screen descriptions to accommodate the display capa- a for ndi !o a M& t for a tem 

bdity of the display type attached to said client. parameter value by sending the appropriate system 

27. The process of claim 1, further comprising the step of: parameter value to said client. 

providing a direct mode of operation in which certain user 37. apparatus of claim 29, said console application 

actions are communicated directly to said server. programming interface further comprising: 

28. The process of claim 1, further comprising the step of: a module for updatmg the appropriate system parameter 
providing a component level event driven mode of opera- 60 value with the value sent by a client. 

tion in which all user actions are communicated 38. Tbe apparatus of claim 29, said console application 

directly to said server. programming interface further comprising: 

29. An apparatus for displaying user interface screens on a module for responding to a client's screen request by 
a plurality of dissimilar display devices utilizing a unified sending the appropriate generic screen description to 
interface protocol, comprising: 65 sa i d client through a network. 

a console application programming interface located on a 39. The apparatus of claim 38, said console application 

server; programming interface further comprising: 
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a module for sending the key value corresponding to said 
appropriate generic screen description to said client 
through a network. 

40. The apparatus of claim 29, said console application 
programming interface further comprising: 

a module for responding to a client's request for a system 
parameter value by sending the appropriate system 
parameter value to said client through a network. 

41. The apparatus of claim 29, wherein said generic user 
interface screen descriptions are structured to allow each 
screen to be displayed on any one of said dissimilar display 
devices. 

42. The apparatus of claim 29, further comprising: 
an interface code interpreter located on said client; 
said interface code interpreter comprising a list of display 

type profiles; 

said interface code interpreter comprising a module for 
selecting the appropriate display type profile from said 
display type list that is the closest equivalent to said 
client's display type profile; 

said interface code interpreter comprising a module for 
receiving said generic interface screen descriptions 
from said server; and 

said interface code interpreter comprising a module for 
displaying said screen descriptions to a user using said 
selected display type profile to interpret said screen 
descriptions. 

43. The apparatus of claim 29, further comprising: 
an interface code interpreter located on said client; 
said interface code interpreter comprising a module for 

receiving said generic interface screen descriptions 
from said server, and 
said interface code interpreter comprising a module for 
displaying said generic interface screen descriptions on 
said client to a user by combining said screen descrip- 
tions to accommodate the display capability of the 
display type attached to said client. 

44. The apparatus of claim 29, further comprising: 
an interface code interpreter located on said client; 
said interface code interpreter comprising a module for 

receiving said generic interface screen descriptions 
from said server; and 
said interface code interpreter comprising a module for 
displaying said generic interface screen descriptions on 
said client to a user by displaying as much of the 
contents of said screen descriptions to accommodate 
the display capability of the display type attached to 
said client. 

45. The apparatus of claim 29, said console application 
programming interface further comprising: 

a module for converting said generic screen descriptions 
into protocol screen descriptions. 

46. The apparatus of claim 45, said console application 
programming interface further comprising: 

a list of display type profiles; and 

a module selecting the appropriate display type profile 

from said display type list that is the closest equivalent 

to said client's display type profile; 
wherein said updating module sends said protocol screen 

descriptions to said client according to said selected 

display type profile. 

47. The apparatus of claim 45, wherein said protocol 
screen descriptions are created in such a manner as to allow 
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each screen to be displayed on any one of said dissimilar 
display devices. 

48. The apparatus of claim 45, further comprising: 
an interface code interpreter located on said client; 
said interface code interpreter comprising a list of display 

type profiles; 

said interface code interpreter comprising a module for 
selecting the appropriate display type profile from said 
display type list that is the closest equivalent to said 
client's display type profile; 

said interface code interpreter comprising a module for 
receiving said protocol screen descriptions from said 
server; and 

said interface code interpreter comprising a module for 
displaying said protocol screen descriptions to a user 
using said selected display type profile to interpret said 
screen descriptions. 

49. The apparatus of claim 45, further comprising: 
an interface code interpreter located on said client; 
said interface code interpreter comprising a module for 

receiving said protocol screen descriptions from said 
server; and 

said interface code interpreter comprising a module for 
displaying said protocol screen descriptions on said 
client to a user by combining said screen descriptions 
to accommodate the display capability of the display 
type attached to said client. 

50. The apparatus of claim 45, further comprising: 
an interface code interpreter located on said client; 
said interface code interpreter comprising a module for 

receiving said protocol screen descriptions from said 
server; and 

said interface code interpreter comprising a module for 
displaying said protocol screen descriptions on said 
client to a user by displaying as' much of the contents 
of said screen descriptions to accommodate the display 
capability of the display type attached to said client. 

51. The apparatus of claim 29, said console application 
programming interface further comprising: 

a module for responding to a client's screen request by 
sending the appropriate protocol screen description to 
said client, 

52. The apparatus of claim 51, said console application 
programming interface further comprising: 

a module for sending the key value corresponding to said 
appropriate protocol screen description to said client. 

53. The apparatus of claim 29, said console application 
programming interface further comprising: 

a module for responding to a client's screen request by 
sending the appropriate protocol screen description to 
said client through a network. 

54. The apparatus of claim 53, said console application 
programming interface further comprising: 

a module for sending the key value corresponding to said 
appropriate protocol screen description to said client 
through a network. 

55. The apparatus of claim 29, wherein a direct mode is 
provided in which certain user actions are communicated 
directly to said server. 

56. The apparatus of claim 29, wherein a component level 
event driven mode is provided in which all user actions are 
communicated directly to said server. 
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